如何确立架构的目标是面向运维？还是面向开发？
进入2017H2开始，“夜跑 + 晨读” 的工作模式开始变得不够牢固，“夜跑” 还行，无论多晚到家基本都能跑个30min以上，“晨读” 却有点懈怠，我暂时把它归功于 “天气比较热” 吧，至少能够让我的内心找到一些平衡。
话题的由来
为了调节口味，近期的晨读从原有的 村上春树大选集 改为了技术类公众号碎片化浏览，由于工作的需要，在选题上着重对「分布式数据库」的开源框架或架构信息进行拜读，在阅读完「当当开源Sharding-jdbc，轻量级数据库分库分表」后，结合近年来在平台化演进过程中的点滴进行了思考
先从几个常 '听' 疑问开始：
提疑问：“为什么非要自主研发？”
我觉得：“下载Redis用起来就行了呀，集群及高可用方案官方都提供了，很成熟”
提疑问：“为什么要增加代理层？”
我觉得：“将SDK再次封装下，并把配置外移，便于维护就可以了呀”
提疑问：“为什么要集中化管理，环境统一？”
我觉得：“违背了分布式的基本原则啊，当然应该‘逐一部署，各个击破’啦”
提疑问：“为什么总要变更SDK？”
我觉得：“能不能你们升级别影响我们？测试没资源，而且自动化覆盖率也不够，没法做到全面回归”
这些疑问和见解，在许多公司的平台化演变过程中或多或少的出现过，当然，纯靠 “堆人+堆机器” 打通关的也不在少数，甚至一年之间系统重构过2-3次的也不在少数
在 「GTLC - Open Space」资产配置时代来临，平台化演进中的问题与挑战 的文章中我提过，互金业务背景的IT演变，多半运行在 “先污染，后治理” 的轨道上，区别无非就是「按技术岗位的横向污染，还是按照业务条线的纵向污染」罢了。
面向运维，还是面向开发
当今DevOps可以说是如日中天，只要IT技术话题中不包括AI、大数据、云或DevOps这样的热门词语，那还是闭上嘴巴，免得遭来白眼；
活在当下，正视前方
大部分从事于以业务产品为核心竞争力的企业的小伙伴们，还是需要时常的低下头，摸着自己的前胸问问自己 “本月的目标实现了吗？是否偏离了初始的目的？”
就像近期我们团队时长挂在嘴边的一句话 “这日子还要过下去是吗？先把把你那些飘在空中的东西搁一搁行吗？”
这绝对不是简单的 “问题驱动” ，“聚焦型人物性格”，甚至是 “不懂规划与掌握未来”，规划人人会做，关键是如何能够 「在仰望心空的同时，坚定不移的脚踏实地」，所以需要结合 “自身的业务特点、历史发展历程、技术文化价值观”之后，再来其他的
原因 - 选择面向运维（策略）
技术松耦合：轻量级SDK，把更多的逻辑与规则放到代理层实现；
产品化理念：「缓存系统」与 「支付系统」，都是一种产品，只是服务对象不同；
快速化迭代：每个系统之间都能够独立发布，就算大版本升级也尽量互不干涉；
快速化部署：当出现故障、冗余或性能需求时，能够更快、更灵活的变更规则与逻辑；
理由 - 难以面向开发（痛点）
发布模式：暂不支持「持续集成、持续交付、持续部署」；
业务线多：资产配置时代，每类产品都是一套完整的系统，如保险、公募基金、私募基金、以及……；
测试方式：黑盒测试占比极高，自动化测试正在路上；
历史累计：从一个程序，变成一坨程序，变成一大坨程序，连用的JDK&第三方包都不一样，更别说开发框架了；
资源投入：人力资源与时间资源都紧靠业务需求，污染的速度大大的超过治理的速度；
结束语
上面的「原因」与「理由」，只是一个总结，大体的思路其实在 「GTLC - Open Space」资产配置时代来临，平台化演进中的问题与挑战 中也提到过，只是视角不同罢了，如果遇到相同的业务场景与处境，大可直接套用
不过话说回来，在我的脑海里，一直认为分享更多代表着一种经验的传承向往，为什么说是向往？因为你表达的是你自己，和别人没有半毛钱关系，大量的事实证明，绝大多数的经验只能用来借鉴、开脑洞，如果直接拿来就用，那恭喜你，你又为自己挖了一个大坑
本次文章的废话显然多了一些，把他理解为唠叨也行，称述现实也罢，希望这些话给大家或是我自己一种启发，一种标记，一种沉淀……
最近技术类文章：
扫描二维码或手动搜索微信公众号【吃草的罗汉】
欢迎转载，带上以下二维码即可
点击“阅读原文”，所有【吃草的罗汉】近期的文章汇总
↓↓↓